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BEST  AVAILABLE  TECHNOLOGIES  (BATs) 
FOR  COMPUTER  SECURITY 


INTRODUCTION 

Over  more  than  a  decade,  government,  industry,  and  academic  centers  have  invested  substantial 
resources  in  techniques  for  developing  secure  computer  systems.  A  good  deal  has  been  learned  about 
the  problem,  and  a  number  of  approaches  have  been  explored.  But  what  useful  advice  can  we  give  to 
those  about  to  embark  on  a  system  development?  If  the  application  requires  a  multilevel  secure  sys¬ 
tem,  how  should  the  developer  proceed?  The  purpose  of  this  report  is  to  summarize  past  experience 
and  to  guide  developers. 

The  next  section  lists  a  few  general  assumptions  about  the  system  developer's  environment.  The 
third  section  describes  past,  present,  and  planned  projects  that  have  attempted  to  build  secure  computer 
systems.  A  brief  discussion  of  each  system  listed  in  the  tables  can  be  found  in  Appendix  A  The 
fourth  section  summarizes  the  experience  gained  in  developing  secure  systems  by  listing  a  number  of 
techniques  and  applications  (alphabetically  by  "buzzword")  and  providing  a  brief  discussion  of  each. 
The  fifth  section  provides  advice  to  developers,  organized  by  the  phases  of  the  system  development 
cycle. 


There  is  no  simple  recipe  for  creating  a  multilevel  secure  system.  The  "three-lajer"  security  ker¬ 
nel  approach,  in  which  application  programs  execute  on  an  operating  system  emulator  that  interfaces  to 
the  security  kernel,  has  yet  to  produce  a  system  that  is  efficient  enough  for  practical  use  (although  there 
is  some  hope  that  kernels  tailored  to  specific  applications  may  yet  achieve  this  goal).  There  has  been 
considerable  work  on  formal  specification  and  program  verification  techniques,  but  the  tools  available  to 
support  these  activities  require  further  development  before  they  can  be  employed  in  development 
efforts. 

To  be  secure,  a  computer  system  must  reliably  enforce  a  specified  policy  for  accessing  the  data  it 
processes  while  it  accomplishes  the  functions  for  which  it  was  built  Since  software  engineering  has  as 
its  goal  the  production  of  reliable,  maintainable  programs  that  perform  according  to  their  specifications, 
the  best  techniques  developed  for  software  engineering  should  be  the  cornerstone  of  efforts  to  develop 
secure  computer  systems. 

The  principal  recommendations  to  developers  are  (1)  that  they  consider  the  security  requirements 
of  each  system  as  part  of  its  functional  requirements  rather  than  as  a  separate  set  of  requirements;  (2) 
that  they  continue  to  think  about  security  throughout  the  design  and  implementation  of  the  system;  and 
(3)  that  they  use  the  best  available  software  engineering  technology  Ill. 

ASSUMPTIONS 

We  assume  that  the  developer  is  to  construct  a  system  for  some  particular  application  (e.g.,  packet 
switching,  message  processing,  software  development)  and  that  he  has  substantial  control  over  the 
choice  of  hardware  for  the  system,  the  choice  of  software  design  and  documentation  strategy,  and  the 
choice  of  validation  and  verification  strategy.  He  will  have  somewhat  less  control  over  the  choice  of 
programming  language;  he  will  have  much  less  control  over  the  interfaces  required  of  his  system;  and 
he  will  have  still  less  control  over  the  set  of  systems  with  which  the  new  system  is  required  to  interface. 
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CASES  OF  INTEREST 


We  choose  not  to  list  all  or  the  journal  articles,  memoranda,  research  papers,  and  so  forth,  relat¬ 
ing  to  computer  security  that  have  been  published  in  the  last  decade  or  so.  In  any  cast/.  Tew  of  these 
have  the  weight  of  actual  system  developments  behind  them.  This  section  summarize^  those  projects 
over  the  last  10  to  IS  years  (including  currently  underway  and  planned  projects)  that  have  included 
significant  efforts  to  provide  secure  software  systems.  Although  there  have  been  no  deliberate  omis¬ 
sions  to  the  list,  it  is  possible  that  some  developments  have  been  overlooked.  The  following  questions 
were  asked  about  each  system: 

I 

1.  When  did  its  development  begin? 


2.  Who  sponsored  it  (i.e.,  paid  for  it)? 

3.  Who  built  it? 


I 


I 

/ 


4. 

5. 

6. 


What  were  its  security  goals? 

Wliat  approach  was  used  to  reach  these  goals? 


/ 

/ 

/ 

i 


Were  formal  specifications  used?  If  so,  in  what  language  were  they  written? 
Who  wrote  them? 


7.  Was  any  verification  done?  If  so,  what  tools  were  used?  Who  used  them? 


8.  What  hardware  was  the  system  built  on? 

9.  What  programming  language(s)  were  used? 

10.  If  it  was  built,  did  the  system  perform  adequately  for  some  practical  use? 

11.  If  installed,  was  it  certified  for  operation  with  classified  data?  If  so,  what  mode? 


12.  Was  it/is  it  installed?  Where? 


13.  What  lessons  were  learned? 


The  answers  to  these  questions  (except  the  last)  are  given  in  Tables  1  to  3.  The  abbreviations 
used  in  these  tables  are  listed  in  Table  4.  Brief  comments  about  each  project,  summarizing  noteworthy 
aspects  and  lessons  learned,  are  provided  in  Appendix  A.  The  reader  is  cautioned  that  some  of  this 
information  is  subject  to  change  (particularly  for  projects  underway  or  planned)  and  parts  of  it  are  the 
personal  conclusions  of  the  author  of  'his  report.  The  bibliography  (Appendix  B)  provides  additional 
sources  of  information  on  the  projects  listed  in  Tables  1  to  3,  but  the  literature  consists  largely  of 
technical  reports;  old  reports  may  be  hard  to  obtain,  and  reports  on  new  projects  have  yet  to  be  written. 

EXPERIENCE  WITH  TECHNIQUES  AND  APPLICATIONS 

To  distill  the  lessons  from  these  projects,  it  is  helpful  to  view  them  according  to  the  various  tech¬ 
niques  they  have  used  and  the  applications  that  have  been  tried.  Listed  alphabetically  in  this  section  are 
various  technical  concepts  and  application  areas  for  developing  secure  systems,  together  with  comments 
concerning  experience  with  each. 
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Table  2  —  Projects  Under  Way* 


System 

When 

Started 

Who 

Paid 

Who 

Built 

Goals 

Approach 

Form 

Spec. 

Vert- 

fle 

Hard¬ 

ware 

Prog. 

Lang. 

Prf  / 
Cert 

Where 

Installed 

KVM/370 

1976 

ARPA 

SDC 

security 

kernel  ml 

1LS, 

TLS 

IBM/ 

Jovial 

NC 

(NATO 

AF 

retrofit 

VMs.  TPs 

SLS, 

ITP 

370 

JJ 

(M) 

(DCA) 

DC  A 

VM/370 

l-J 

KSOS 

late 

NSA 

FACT 

Secure 

kernel, 

TLS 

TLS 

PDP- 

MDLA 

N 

Logicon, 

(Ksos-tn 

70s 

ARPA 

UNIX 

emulator, 

SPCL 

SRI 

II 

(M) 

MITRF. 

Navy 

TPs 

SCOMP 

late 

I1YWL 

HYWL 

Secure 

kernel, 

TLS 

TLS 

HYW1 

UCLA 

NC 

(MITRE) 

(KSOS-6) 

70s 

ARPA 

UNIX 

emulator, 

SPCL 

SRI 

Lvl 

PSCL, 

(M) 

(NSA) 

DCA, 

TPs,  hdwe 

HYWL 

HYWL 

6 

C 

NSA, 

assist 

Navy 

ACCAT 

late 

Navy 

LGCN 

sanitize/ 

TPs  on 

some 

(some) 

PDP- 

c. 

NC 

NOSC 

GUARD 

70s 

ARPA 

filter 

KSOS 

SPCL? 

It 

MDLA 

(M) 

Logicon 

DBMS  to 
DBMS 

GYP 

LSI 

1980 

Navy 

IPS 

sinale 

TPs  on 

(F.u- 

No 

LSI- 

Hu* 

NC 

7 

GUARD 

operator 

bare 

did) 

II 

clid 

(M) 

ACCAT  GD 

hardware 

FORSCOM 

1980 

DCA 

LGCN 

filter— 

TPs  on 

(GYP) 

(GYP) 

PDP- 

c 

D 

Army 

GUARD 

terminal- 

to-host. 

w/operator 

UNIX 

II 

(MDLA) 

<M, 

FORSCOM 

SDC 

iate 

SDC 

secure 

tailor 

NO 

NO 

PDP- 

UCLA 

7 

SDC 

Comm. 

70s 

comm. 

UCLA  ker- 

II 

PSCL 

7 

Kernel 

•hoc. 

ncl 

AUTODIN 

late 

DCA 

wu. 

secure 

kernel- 

Yes, 

Yes 

PDP 

C, 

NC 

(DIN  1 

It 

70s 

CSC, 

comm 

based 

post 

ITP 

11 

asm 

(M?) 

sites) 

FACC 

proc. 

arch. 

hoe 

SACDIN 

late 

AF 

ITT 

secure 

kernel- 

TLS 

TLS 

IBM 

asm 

NC 

(SAC 

70s 

IBM 

comm 

based 

SPCL 

SRI 

Se- 

(M?) 

sites) 

proc 

arch. 

SYTK 

ries  1 

COS/NFE 

late 

DCA 

DTI 

secure 

•HUB-  TM 

TLS 

TLS 

PDP- 

PSCL 

NC 

(WWMCCS 

70s 

WWMCCS/ 

kernel, 

l-J 

ITP 

II 

(M) 

sites) 

DIN  II 

trusted 

NFF. 

modules 

GNOSIS 

early 

TymS 

TymS 

segregate 

Capabili- 

No 

No 

IBM/ 

asm 

NC 

Tymshare 

70s 

client 

ties 

370 

(M?) 

data 

PSOS 

1980 

NSA 

FACC 

Secure 

Spec  and 

Yes 

Yes 

HYWL 

_ 

NB 

HYWL 

Op  Sys 

Ver  en¬ 
tire  OS 

(MAN) 

(M) 

MetU|c 

1981 

Navy 

UTX 

Alter  & 

TPs, 

GYP 

GYP 

LSI- 

GYP 

NC 

(OSIS) 

Flow  Mod- 

transform 

fill  ver. 

11 

(M) 

ulator 

output 

SASS 

1978 

Navy 

npgs 

secure 

multi- 

no 

no 

Zilo( 

asm? 

NC 

PGS 

archival 

micro- 

8000s 

(M) 

file  sys. 

kernel 

*ror  explanation  of  abbreviations  see  Table  4. 
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System 

When 

Started 

Who  Who 
Pays  Builds 

Goals 

Approach 

RAP 

early 

80s 

early 

NASA  MTRE 

KAE?  MTRE 

filter- 

TPs  on 

KSOS  ? 

■  ■> 

GUARD 

KAIS 

terminal- 
to*host, 
no  oprtr. 

«  ■) 

GUARD 

80s 

WWMCCS 

early 

OCA 

MLS  nets 

Sep.  nets 

Local 

80s 

for  WWMCCS 

w/GUARD 

Net 

nodes 

for  Internet 

MITRE 

1480 

AE?  MTRE 

secure 

process 

MLS 

intelli- 

per  pro* 

terminal 

gent 

cessor. 

terminal 

MLOs 

NRL 

1981 

Navy  NRL 

MLS  ms*. 

appl. -based 

MMS/TOMS 

SOC 

system/ 

sec.  model, 

BBN 

database 

prototype 

MITRE 

1981 

Navy  MTRE 

secure 

tailored 

DBMS 

MRS  OBMS 

kernel 

Kernel 

EIFF.L  2 

late 

GDR?  GDR 

MLS  air- 

kernel 

70s 

SMNS 

traff  ctl. 

based? 

TLE? 

Canadian 

early 

?  ? 

7 

Msritime 

80s 

Command 

No  No 


NC  (WWMCCS 
(M)  sites) 


NC  (MITRE) 
(M?> 


(Y)  (Y?)  SCMP  C?  NC  (MITRE) 


•For  explanation  of  abbreviations  see  Table  4. 
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Table  4  —  Abbreviations  Used  in  Tables  1  to  3 

?  —  data  unknown  or  uncertain 

( )  —  enclosed  data  indicate  plans,  not  accomplishments 

Performance  Codes 

N  —  No  —  performance  not  adequate  for  operational  use 
Y  —  Yes  —  system  could  be  used  operationally 
D  -  Demo  —  system  built  as  prototype  or  demo  only 
NC  —  System  not  yet  complete  enough  for  evaluation 
NB  —  System  never  built 

Certification  Codes 

M  —  Multilevel 
C  —  Controlled 
S  —  System  high 
D  —  Dedicated 
N  —  Not  certified 

Hardware 

GE  645  Specially  modified  GE  635.  When  Honeywell  bought  GE,  the  numbers  changed. 

This  is  the  original  MULTICS  machine  number.  New  Honeywell  models  have 
since  been  introduced  and  the  commercial  version  ef  MULTICS  runs  on  the  newer 
hardware  (Honeywell  6180). 

Lvl  6  Honeywell  Level  6  minicomputer 

SCMP  SCOMP  —  Honeywell  Level  6  with  added  Security  Protection  Module  (SPM) 

C ompanies/La  bora  lories 


BBN 

Bolt  Beranek  and  Newman,  Inc. 

CR 

Christian  Rdvsing  (Denmark) 

BTL 

Bell  Telephone  Laboratories 

CSC 

Computer  Sciences  Corp. 

DTI 

Digital  Technology,  Inc. 

FACC 

Ford  Aeiospare  and  Communications  Corp. 

HYWL 

Honeywell 

IPS 

I.P.  Sharp  Associates 

ISI 

Information  Sciences  Institute  (USC) 

LGCN 

Logicon 

MTRE 

MITRE  Corp. 

SDC 

System  Development  Corporation 

SMNS 

Siemens  (W.  Germany) 

SRI 

SRI  International 

SYTK 

Sytek 

TLF 

Telefunken  (W.  Germany) 

TymS 

Tymshare,  Inc. 

wu 

Western  Union 
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Table  4  (Continued)  —  Abbreviations  Used  in  Tables  1  to  3 


Government  Organizations 


AFCP 

Air  Force  Command  Post  (located  in  Pentagon) 

ARPA 

DoD  Advanced  Research  Projects  Agency 

AFDSC 

Air  Force  Data  Services  Center 

AF 

Air  Force 

CIA 

Central  Intelligence  Agency 

C1NCPAC 

Commander-in-Chief,  Pacific 

DCA 

Defense  Communications  Agency 

DIA 

Defense  Intelligence  Agency 

FCDSSA 

Fleet  Combat  Direction  Systems  Support  Activity 

NATC 

Naval  Air  Test  Center,  Patuxent  River 

NMCSSC 

National  Military  Command  System  Security  Center 

NPGS 

Naval  Postgraduate  School 

NRL 

Naval  Research  Laboratory 

NSA 

National  Security  Agency 

Languages/T ools 

asm 

Assembly  language  (for  whatever  machine  indicated) 

GYP 

Gypsy  —  programming  and  assertion  language,  with  verification 
tools,  developed  at  University  of  Texas 

1-J 

Ina  Jo™  —  specification  language  supported  by  SDC 

ITP 

Interactive  Theorem  Prover  —  supported  by  SDC,  used  w/lna  Jo 

MAN 

Manual  proofs 

MOL 

Macro  Language  for  IBM/360 

MDLA 

Modula 

PSCL 

Pascal 

SPCL 

SPECIAL  —  specification  language,  tools  available  from  SRI 

UCLA  PSCL  Pascal  to-C  translator  implemented  at  UCLA  for  a  "verifiable" 

Pascal  subset 

UNIX 

UNIX™  operating  system,  originally  developed  by  Bell  Laboratories 

VDL 

Vienna  Definition  Language 

Miscellaneous 

AM 

Access  matrix 

B+LP 

Bell  and  LaPadula 

GD 

GUARD 

GP 

General  purpose 

HWM 

High  water  mark 

MLO 

Multilevel  object 

MLS 

Multilevel  secure 

SLS 

Second-level  specification 

TLS 

Top-level  specification 

TP 

Trusted  process 

TS 

Time  sharing 
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Capabilities 

A  capability  is  usually  defined  as  an  unforgeable  ticket  that  grants  its  holder  a  specific  kind  of 
access  to  a  particular  object;  capabilities  can  be  implemented  as  virtual  addresses,  with  additional  bits  to 
define  allowed  access  modes.  Capabilities  provide  a  mechanism  for  controlling  access  to  objects,  not  for 
implementing  security  policy.  The  provision  of  security  depends  on  the  design  of  the  system,  which 
may  be  based  on  the  use  of  capabilities.  Nevertheless,  they  are  an  appealing  tool  for  structuring  the 
implementation  if  the  appropriate  hardware  is  available.  Without  the  appropriate  hardware,  there  is 
considerable  evidence  that  capability-based  systems  perform  poorly  (but  see  GNOSIS).  Architectures 
based  on  the  manipulation  of  capabilities  are  still  more  touted  than  tried,  although  hardware  architec¬ 
ture  trends  seem  to  be  moving  in  this  direction  (e.g.,  the  Plessey  S250,  the  IBM  System  38,  and  the 
Intel  432).  The  UCLA  DSU  kernel  (and  hence  the  SDC  Communications  Kernel)  employs  the  con¬ 
cept  of  a  capability  but  is  constrained  to  use  the  addressing  hardware  of  a  PDP-11.  PSOS  is  intended  to 
employ  a  capability  architecture  and  will  be  an  interesting  test  case,  if  it  is  built.  The  GNOSIS  effort 
claims  to  be  based  on  an  implementation  of  capabilities  on  standard  IBM  370  hardware.  No  secure  sys¬ 
tem  developments  using  the  Plessey  hard  vare  have  been  reported. 

Databases 

None  of  the  secure  system  development  efforts  so  far  nave  tried  to  deal  with  the  complexities  of 
securing  a  database  management  system  shared  among  a  variety  of  users.  There  is  substantial  theoreti¬ 
cal  evidence  that  statistical  databases  are  impossible  to  secure  against  inference,  but  there  are  some 
techniiues  that  can  make  it  more  difficult  for  information  to  be  compromised. 

Encryption 

There  are  increasing  efforts  to  apply  encryption  within  computer  systems.  Protection  and  distribu¬ 
tion  of  keys  then  becomes  a  critical  issue.  Because  they  were  generally  trying  to  secure  the  operating 
system  itself,  which  would  presumably  control  access  to  keys,  none  of  the  systems  listed  in  Tables  1  to 
3  used  encryption  as  a  technique  for  protecting  information. 

Kernels 

Many  of  the  projects  listed  above  sought  to  demonstrate  the  practicality  of  the  security  kernel 
approach.  A  security  kernel  is  a  small  subset  of  a  system  that  is  responsible  for  its  security  and  so  must 
provide  complete  validation  of  program  references,  must  be  isolated  (tamperproof),  and  must  operate 
correctly  according  to  a  stated  security  policy.  The  results  so  far  are  mixed,  at  best.  The  three-layer 
approach  (user  programs  running  on  an  operating  system  emulator  running  on  a  security  kernel)  has 
yet  to  produce  a  system  efficient  enough  for  operational  use.  The  KSOS  represents  the  most  serious 
attempt  to  use  this  approach  to  build  an  operational  system,  and  it  has  fallen  far  short  of  its  perfor¬ 
mance  goal  of  approximately  50%  degradation  of  unmodified  UNIX  on  the  same  hardware.  Some 
observers  lay  the  blame  at  the  feet  of  the  PDP-11  hardware.  Performance  data  are  just  becoming  avail¬ 
able  on  the  kernel  for  the  SCOMP,  which  is  built  on  hardware  specifically  modifitu  to  assist  security. 
Honeywell  now  plans  to  build  a  minimal  operating  system  interface,  including  a  simple  file  system,  out¬ 
side  of  the  kernel,  instead  of  developing  a  full  emulator.  The  KVM/370,  which  is  more  on  the  order  of 
a  retrofit  kernel,  has  been  brought  up  on  IBM  and  Amdahl  hardware,  and  early  indications  are  that  it 
offers  about  50%  of  the  performance  of  unmodified  VM370  on  the  same  hardware.  SHARE-7  is  now 
described  as  having  a  security  kernel,  but  appears  to  have  been  constructed  more  on  the  virtual 
machine  model,  with  kernel  terminology  superimposed  on  it  after  the  fact.  The  SDC  Communications 
Kernel,  which  seems  to  be  the  kernel-based  system  closest  to  delivering  a  useful  product  at  present,  is 
really  a  two-layer  approach:  the  kernel  is  carefully  tailored  for  the  application  and  the  application  runs 
directly  on  the  kernel.  The  AUTODIN  II  kernel  is  rarely  cited  as  a  good  example  of  anything.  Recent 
reports  from  the  Christian  Rdvsing  company  in  Denmark  may  indicate  a  significant  advance  in  the 
development  of  an  operational  system  based  on  a  security  kernel. 
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Measures 

There  are  no  useful  quantitative  measures  at  present  for  defining  the  relative  "security"  of  various 
systems.  None  of  the  projects  listed  in  the  tables  has  addressed  this  problem  seriously.  The  only  realis¬ 
tic  measures  would  seem  to  be  the  difficulty  of  penetration  or  the  rate  of  unauthorized  information  flow 
out  of  the  system  under  specified  conditions. 


Network  Architectures 

Although  papers  are  being  published  in  this  area,  novel  architectures  for  secure  networks  are  lack¬ 
ing.  While  some  of  the  efforts  described  have  developed  machines  for  use  as  network  switches 
(AUTODIN  II,  SACDIN),  none  has  provided  innovative  solutions  to  network  security  problems. 
Topics  under  study  include  the  use  of  public  key  encryption  algorithms  and  making  communication 
protocols  secure.  End-to-end  encryption  does  appear  to  be  coming  closer  to  being  practical.  The 
WWMCCS  local  network  project  may  contribute  so  nething  to  the  solution  of  this  problem.  (See  also 
Protocols.) 

Penetration  Studies 

Every  serious  attempt  that  we  know  of  to  penetrate  a  particular  system  has  succeeded.  Informa¬ 
tion  on  penetration  studies  applied  to  the  systems  listed  in  the  tables  is  sparse.  A  penetration  study  of 
VM/370  (CP/67)  done  by  SDC  did  conclude  that  it  was  significantly  more  difficult  to  break  into  that 
system,  which  is  based  on  virtual  machines,  than  into  some  others. 

Protocols 

See  Network  Architectures.  The  major  problem  is  how  to  limit  the  unauthorized  information  flow 
possible  in  the  control  information,  which  often  has  to  be  transmitted  in  the  clear  (unencrypted). 

Risk  Assessment 

A  risk  assessment  attempts  to  characterize,  within  a  specific  installation,  the  assets  of  a  system, 
the  threats  to  them,  and  the  system's  vulnerabilities  to  those  threats.  Risk  assessments  of  computer 
installations  are  being  conducted  at  a  number  of  installations.  Since  risk  assessments  consider  condi¬ 
tions  at  a  specific  site,  the  most  general  assessment  that  can  be  done  by  the  developer  is  an  analysis  of 
the  vulnerabilities  of  the  system  in  general.  Vulnerability  analyses  may  be  classified,  since  they  may 
reveal  exploitable  system  flaws.  There  has  been  an  example  risk  assessment  conducted  on  GUARD, 
partly  to  evaluate  risk  assessment  methodology.  Of  the  completed  systems,  AFDSC  MULTICS  and 
ADF.PT-50  are  the  most  likely  to  have  had  such  analyses  done.  A  risk  assessment  of  SHARE-7  has 
beeti  conducted.  Presumably,  a  vulnerability  analysis  will  be  done  for  AUTODIN  II.  The  most  difficult 
problem  in  any  risk  assessment  is  what  value  to  attach  to  the  data  at  risk. 

Security  Models 

Cf  the  projects  listed  in  the  tables,  the  MITRE  kernel,  MULTICS  security  enhancements  and  ker¬ 
nel,  KSOS,  SCOMP,  GUARD,  MME  message  systems,  AUTODIN  II,  KVM/370,  and  SACDIN,  all  are 
based  on  the  Bell  anu  LaPadula  model.  The  UCLA  kernel  implemented  underlying  controls  for  capa¬ 
bilities,  with  the  specific  Bell  and  LaPadula  rules  implemented  in  a  "policy  manager"  module.  This  uni¬ 
formity  seems  to  be  caused  more  by  government  direction  than  by  superiority  of  the  model.  In  fact,  it 
is  now  being  recognized  that  models  that  can  more  closely  reflect  applications  are  necessary,  particularly 
in  dealing  with  data  bases.  Still,  the  Bell  and  LaPadula  model  (and  its  restatement  in  terms  of  informa¬ 
tion  flow)  is  the  baseline  for  the  field  tsee  Ref.  2  for  a  detailed  discussion). 
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Specification  Techniques 

Parts  of  several  of  these  systems  have  been  specified  formally.  Systems  and  tools  employed 
include  SPECIAL/HDM/Boyer-Moore  Theorem  Prover  (SRI),  Gypsy  (University  of  Texas),  Ina 
Jo/ITP  (SDC),  and  AFFIRM  (ISI).  There  is  evidence  (e.g.,  KSOS  and  SCOMP)  that  programmers  can 
write  formal  specifications  (after  some  training)  and  that  some  errors  (security  flaws)  are  exposed  by 
the  use  of  automated  tools  to  check  (verify)  the  specification.  However,  the  m^jor  benefits  for  security 
seem  to  be  that  other  humans  (system  developers  or  reviewers)  can  understand  what  the  specification 
says  and  find  flaws  (security  or  other)  by  reviewing  the  specification  manually,  despite  the  often  forbid¬ 
ding  appearance  of  a  formal  specification.  This  finding  is  partly  a  comment  on  the  state  of  the  tools 
available  for  formal  specification  and  verification,  Evidence  from  these  projects  is  that  the  tools 
currently  available,  though  improving,  are  best  characterized  as  research  vehicles,  not  production- 
quality  aids  to  software  development. 

Verification  Techniques 

Most  of  the  comments  on  specification  techniques  apply  here  as  well.  Verification  of  security 
properties  of  top-level  specifications  seems  to  be  within  (but  fairly  near  the  edge  of)  the  current  state  of 
the  art.  Verification  of  actual  code  (in  some  compilable  language)  is  still  very  hard  for  the  available 
tools  and  usually  requires  considerable  human  intervention.  Despite  apparent  progress  in  research  in 
this  area,  the  present  s> stems  are  some  distance  from  practical  use  as  system  development  tools.  The 
benefits  to  be  had  from  attempting  verification  seem  to  be  software-engineering  ones:  it  forces  the 
designer/implementor  to  think  hard  about  what  he  is  doing  and  leaves  an  extensive  documentation  trail 
for  others  to  review. 

Virtual  Machines 

The  KVM/370  is  the  prime  example  of  a  secure  system  based  on  this  approach;  SHARE-7  is 
another  example.  This  organization  helps  in  isolating  individual  users  at  separate  security  levels,  and  in 
systems  where  isolation  is  all  that  is  required,  it  is  the  best  available  approach.  However,  experience 
indicates  that  such  isolation  is  rarely  what  is  really  needed;  if  extensive  communication  between  users 
and  across  security  levels  is  required,  this  organization  can  get  in  the  way. 

Virtual  Memory 

This  is  one  tool  for  organizing  computer  systems  that  it  would  seem  foolish  for  a  developer  of  a 
new  secure  system  to  forgo.  A  persistent  problem  with  many  of  the  efforts  listed  in  the  tables  has  been 
the  small  virtual  address  space  of  the  PDP-11  and  its  approach  toward  virtualization  of  devices. 

ADVICE  FOR  THE  DEVELOPER 

What  are  the  lessons  for  the  developer  of  a  new  system?  It  is  important  to  distinguish  between 
technologies  that  are  available  and  useful  today  and  research  approaches  that  appear  promising  but  are 
unproven.  There  is,  at  present,  no  proven  technology  that  can  assure  that  the  system  being  developed 
will  be  secure.  Those  techniques  that  have  been  tried  have  met  with  varying  degrees  of  success.  It  is 
difficult  to  give  objective  measures  for  these  degrees  of  success  because  there  are  no  good  measures 
that  can  be  applied  to  rank  the  security  of  various  systems. 

Listed  below  are  the  best  available  approaches  for  incorporating  security  into  a  system  under  the 
stated  constraints.  Each  is  listed  under  the  appropriate  phase  of  the  system  development  cycle.  Many 
of  these  simply  represent  good  system  design  and  software  engineering  practices. 
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Requirements 

Determining  the  requirements  for  security  in  a  system  is  crucial,  because  they  will  affect  the 
entire  structure  of  the  system  software.  Security  is  not  an  "add-on"  feature.  It  must  be  incorporated 
throughout  a  system,  and  the  statement  of  security  requirements  for  a  system  should  reflect  this  fact. 

There  are  at  present  four  different  modes  of  operation  for  which  systems  processing  classified 
information  can  be  accredited:* 


Dedicated'.  All  system  equipment  is  exclusively  used  by  that  system,  and  all  users  are  cleared 
for  and  have  a  need  to  know  for  ail  information  processed  by  the  system; 

System  high:  All  equipment  is  protected  in  accordance  with  requirements  for  the  most  classified 
information  processed  by  the  system,  and  all  users  are  cleared  to  that  level,  but 
some  users  may  not  have  a  need  to  know  for  some  of  the  information; 


Controlled:  Some  users  have  neither  a  security  clearance  for  nor  a  need  to  know  for  some 

information  processed  by  the  system,  but  separation  of  users  and  classified  material 
is  not  essentially  under  operating  system  control;!  and 

Multilevel:  Some  users  have  neither  a  security  clearance  for  nor  a  need  to  know  for  some 

information  processed  by  the  system,  and  separation  of  personnel  and  material  is 
accomplished  by  the  operating  system  and  associated  system  software. 


Definitions  of  these  modes  are  provided  in  DoD  Directive  5200.28  13]. 


A  Request  for  Proposal  (RFP)  should  state  what  modes  of  operation  are  needed  for  the  system 
initially  and  whether  future  operation  in  other  modes  is  planned.  However,  if  the  requirement  for 
security  is  isolated  and  stated  baldly  ("The  system  shall  be  secure"),  bidders  may  view  the  security 
requirement  separately  from  other  system  requirements  and  so  may  propose  infeasible  solutions. 


The  system  architect  should  consider  the  system’s  security  requirements  as  part  of  its  functional 
requirements  from  the  start.  In  this  way  intelligent  trade-offs  can  be  made  where  required  and  a 
coherent  design,  integrating  the  needs  for  functionality  and  security,  can  be  obtained.  If  this  procedure 
is  not  followed,  bidders  may  claim  that  they  can  build  the  system  only  to  discover  that  requirements 
conflict  when  they  are  weil  into  the  development. 

One  illuminating  example  is  that  of  the  military  database  system  that  normally  contains  only 
unclassified  data,  but  during  crises  some  of  its  contents  may  be  classified.  Because  the  requirement  to 
handle  classified  data  was  not  implemented  initially,  its  users  must  either  finance  a  duplicate  system, 
attempt  to  retrofit  security  to  the  existing  system,  or  operate  in  a  manual  mode  during  crises. 


One  way  the  system  architect  can  integrate  the  security  requirements  with  the  functional  require¬ 
ments  explicitly  is  to  specify  the  flows  of  information  (especially  classified  information)  that  will  occur 
in  the  system  and  the  flows  of  authorization.  Particular  places  to  look  for  problems  are  in  the  user 
interface,  in  any  operations  that  cause  information  to  flow  into  or  out  of  the  system,  and  any  places 
where  the  classification  of  information  could  be  changed. 


'Additional  constraints  may  be  placed  on  systems  processing  compartmented  information. 

t"  Essentially"  is  not  further  defined  in  the  official  document*;.  In  practice,  controlled  mode  seems  to  be  applied  to  systems  that 
would  be  considered  as  operating  in  a  multilevel  mode,  but  which  bar  users  with  clearances  below  some  specified  level  from  hav¬ 
ing  access  to  the  system. 
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Trade-offs  in  the  provision  of  security  should  be  identified  and  assessed  as  early  as  possible.  For 
example,  physical  controls  and  computer  hardware  and  software  controls  are  alternative  techniques  for 
protecting  information  stored  on  computers.  If  they  are  not  assessed  as  alternatives  early  in  the  system 
development,  however,  physical  security  will  be  the  de  facto  choice,  because  it  is  much  easier  to  provide 
after  the  fact  than  hardware  and  software  controls.  Unfortunately,  physical  controls  frequently  restrict 
functionality  more  than  comparable  software  controls. 

Within  the  software  and  hardware  design  there  will  be  trade-offs  as  well.  Many  of  these  only  need 
to  be  addressed  in  the  design,  but  the  system  requirements  should  provide  guidelines  on  such  matters 
as  the  granularity  of  protection  needed,  critical  pieces  of  information  that  may  require  special  protec¬ 
tion,  acceptable  bandwidths  for  leakage  channels,  and  so  on.  The  designers  w  II  be  forced  to  make 
decisions  on  these  questions  whether  or  not  guidelines  are  provided;  it  is  in  everyone’s  interest  that 
these  decisions  be  informed,  not  ad  hoc. 

Design 

For  development  of  a  multilevel  secure  system,  security  must  be  considered  early  and  often  dur¬ 
ing  the  design  phase.  As  with  requiiements,  it  cannot  be  added  to  an  existing  design.  The  most  prom¬ 
inent  design  strategy  at  present  is  the  security  kernel  approach,  but  it  is  not  a  proven  technology. 
There  is  evidence  that  use  of  a  security  kernel  can  impose  intolerable  functionality  or  performance  bur¬ 
dens.  Improved  hardware  may  ease  these  burdens  somewhat,  but  there  are  still  substantial  questions 
about  the  viability  of  this  approach.  At  present,  a  system  designer  would  be  well  advised  to  do  the  fol¬ 
lowing: 

•  Study  the  functions  of  the  system,  focusing  on  requirements  for  the  flow  of  classified  information 
■and  the  interface  with  the  user.  Specifically,  note  under  what  conditions  sensitive  information  is 
disclosed  or  modified,  has  its  classification  changed,  or  enters  or  leaves  the  system.  Include 
mechanisms  to  audit  the  use  of  system  functions  that  may  leak  information. 

•  Construct  a  simple  model  of  the  flow  of  information  and  authority  within  the  system.  The  model 
need  not  be  formal,  but  should  be  brief,  precise,  and  simple  enough  to  be  understood  by  both  the 
implementors  and  the  users  of  the  system. 

•  Keep  the  model  and  the  design  consistent.  If  changes  are  required  to  either,  make  corresponding 
changes  to  both. 

•  Develop  a  hierarchical  set  of  design  specifications.  Include  a  top-level  specification  that  reflects  the 
basic  functions  of  the  system  and  the  information-flow  model,  and  a  program  specification  that  is 
sufficiently  detailed  to  allow  outside  reviewers  (and  new  personnel)  to  review  the  code  structure 
and  to  assess  the  information  flows  and  authorization  mechanisms  it  will  have.  As  the  design  is 
created,  have  it  reviewed  at  regular  intervals  both  by  the  potential  users  and  by  individuals 
knowledgeable  in  computer  security.  KSOS,  SCOMP,  the  SDC  Communications  Kernel,  and 
other  projects  have  used  this  approach  with  good  results.  Use  of  formal  specifications  may  be 
helpful,  but  their  use  should  be  contingent  on  training  of  the  implementors  to  the  extent  that 
they  are  competent  to  read  and  update  them.  The  software  tools  presently  available  for  formal 
specification  and  verification  are  still  primarily  research  vehicles,  although  this  situation  may 
change  within  a  few  years. 

•  Choose  hardware  that  reduces  security  problems.  Generally,  hardware  that  provides  good 
mechanisms  for  isolating  different  computations,  simple  and  efficient  ways  to  control  the  flow  of 
information  between  isolated  contexts,  and  a  uniform  way  of  treating  different  kinds  of  objects  is 
desirable.  The  following  features  will  help  in  the  implementation  of  secure  systems:  virtual 
memory,  with  controlled  access  to  the  mapping  registers;  a  device  interface  that  offers  the  possi- 
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bility  of  a  uniform  treatment  of  memory,  flies,  and  devices;  and  the  ability  to  change  addressing 
contexts  rapidly.  Several  machine  states  that  restrict  access  to  critical  portions  of  the  instruction 
set  are  not  required  if  all  accesses  to  data  are  mediated  by  the  virtual  memory  mechanism,  but 
they  can  be  used  as  another  way  of  protecting  critical  operating  system  data  (e  g.,  the  contents  of 
the  mapping  registers). 

Implementation 

The  implementation  should  employ  a  language  for  which  there  is  a  well-understood,  reliable  com¬ 
piler.  There  are  some  languages  (e  g.,  Gypsy,  Euclid)  that  have  been  designed  with  the  intention  that 
programs  written  in  them  be  verified  and  others  (Pascal,  Ada)  for  which  "verifiable  subsets"  have  been 
proposed.  Experience  to  date  indicates  that  a  reliable  compiler  and  the  disciplined  use  of  a 
conventional  language  are  preferable  to  a  relatively  untested  compiler  and  a  "verifiable"  language. 
Assembly  language  should  be  avoided  whenever  possible. 

If  it  becomes  necessary  for  the  code  to  deviate  from  the  specifications,  the  specifications  should 
be  updated  in  parallel  with  the  code  changes.  Go,  J  coding  practices  benefit  the  security  of  the  system 
as  well  as  its  reliability  and  maintainability.  Careful  attention  should  be  paid  to  configuration  control. 

Verification  and  Testing 

Automated  verification  that  a  given  formal  top-level  specification  obeys  the  Bell  and  LaPadula 
security  model  is  within  the  state  of  the  art,  but  it  is  far  from  routine.  Experience  shows  also  that  vir¬ 
tually  all  applications  require  functions  that  violate  the  Bell  and  LaPadula  model.  Thus,  if  the 
specification  is  verified  to  enforce  this  model,  the  implementation  will  deviate  from  it  in  some  respect. 
At  present,  automated  verification  of  the  security  properties  of  substantial  amounts  of  code  is  beyond 
the  state  of  the  art.  These  techniques  hold  promise  for  the  future,  but  there  is  substantial  risk  in 
employing  them  in  a  system  development  that  starts  next  week.  The  verification  of  specific  properties 
of  a  specification  or  small  pieces  of  code  can  be  done  by  hand  or,  if  written  in  suitable  languages,  with 
machine  assistance.  Currently,  the  principal  benefit  of  doing  so  is  that  the  exercise  focuses  a  good  deal 
of  attention  on  the  specification  or  code  at  hand  and  requires  the  doer  to  think  the  problem  through 
very  carefully.  A  few,  but  not  many,  security  flaws  in  systems  have  been  found  through  use  of 
verification  techniques. 

Thorough  testing  continues  to  be  a  necessary  partner  to  careful  design  and  implementation  of  sys¬ 
tems  to  be  operated  in  a  multilevel  secure  mode.  When  test  plans  are  constructed,  specific  attention 
must  be  given  to  testing  the  security  provisions  of  the  system.  If  possible,  the  developer  should 
arrange  for  penetration  tests  and  estimate  the  bandwidths  of  leakage  channels  that  cannot  be  eliminated. 

Operation 

From  the  standpoint  of  security,  the  important  aspects  of  system  operation  are  the  controls  over 
changes  to  the  system  software  and  configuration  and  the  conscientious  use  of  the  security  mechanisms 
provided  by  the  system.  Configuration  control  is  of  central  importance  in  the  operation  of  a  multilevel 
secure  system,  and  the  design  of  the  system  itself  should  assist  in  this  task.  The  maintenance  of  vari¬ 
ous  levels  of  specification,  good  coding  practices,  and  use  of  high-level  languages  all  help. 

One  often  neglected  aspect  of  operations  is  the  monitoring  of  the  audit  trails  that  are  routinely 
collected:  usually  they  arc  too  voluminous  (and  boring)  for  us  to  expect  a  person  to  do  a  reasonable 
job  of  checking  them.  Automated  tools  for  this  purpose  need  close  attention,  since  defeating  the  tools 
becomes  equivalent  to  defeating  the  auditing  controls. 
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SUMMARY 

There  is  no  philosopher's  stone  to  turn  a  given  system  (or  system  design)  into  a  multilevel  secure 
version  of  the  same  system.  The  advice  given  above  boils  down  to: 

•  Consider  securit>  requirements  in  conjunction  with  the  functional  requirements  of  the  system. 

•  Think  about  securi  y  throughout  the  design  and  implementation  of  the  system. 

•  Use  the  best  available  software-engineering  technology. 

•  Be  skeptical.  Many  "modern"  ideas  do  not  yet  work. 
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Appendix  A 

COMMENTS  ON  SECURE-SYSTEM  DEVELOPMENTS 

PROJECTS  COMPLETED 

ADEPT-50:  This  system  was  the  first  to  be  based  on  a  formal  model  of  security.  This  model  (called 
the  High  Water  Mark  model)  allowed  write-downs  (with  authorization)  but  restricted  read-ups. 
Installed  in  the  Pentagon  (AFCP,  NMCSSC),  CIA,  and  SDC,  it  ran  for  several  years.  It  was 
certified  for  system-high  operation  only. 

MUI.TICS:  The  MULTICS  operating  system  (and  the  MULTICS  hardware)  attempted  to  pay  a  good 
deal  of  attention  to  protection,  if  not  to  security.  The  most  significant  innovation  in  this 
respect  was  probably  the  concept  of  rings  of  protection,  in  which  inner  (lower  numbered)  rings 
are  more  privileged  than  outer  rings.  The  architecture  generalized  the  concept  of  a  two-state 
(supervisor  and  user)  machine  to  that  of  an  w-state  machine,  with  one  state  for  each  ring.  For 
the  original  MULTICS  machine,  «“16.  In  practice,  nearly  all  of  the  original  MULTICS 
privileged  software  was  in  the  innermost  ring.  This  result  was  probably  partly  due  to  the  fact 
that  handling  ring  crossings  was  initially  done  in  software,  making  it  expensive  (time  consum¬ 
ing).  Later,  hardware  for  ring  crossing  was  added  and  there  were  efforts  to  distribute  the 
operating  system  components  across  several  rings.  These  efforts  were  not  very  successful. 
MULTICS  also  included  an  implementation  of  access  lists  for  files  (segments)  and  a  hierarchi¬ 
cal  file  system.  Verification  and  security  models  were  not  considerations  in  the  MULTICS 
development.  Performance  of  MULTICS  was  poor  for  several  years,  but  gradually  improved  to 
the  point  that  Honeywell  now  markets  MULTICS  as  a  supported  product.  The  current 
hardware  is  the  Honeywell  6180. 

AFDSC  MULTICS  (MULTICS  Security  Enhancements):  The  Bell  and  LaPadula  model  was  applied  to 
MULTICS  —  MULTICS  objects  had  classifications  attached  to  them  and  the  ’-property  and 
simple  security  condition  were  enforced.  No  effort  was  made  to  isolate  the  security-relevant 
code  or  to  restructure  MULTICS  into  a  kernel.  The  system  was  installed  in  1974  at  the  Air 
Force  Data  Services  Center  in  the  Pentagon  and  has  been  certified  to  operate  with  both  TS  and 
S  data  and  with  some  users  cleared  only  to  S. 

MULTICS  Security  Kernel:  Following  the  MULTICS  security  enhancements,  this  was  an  effort  to  see 
if  the  MULTICS  operating  system  could  be  restructured  as  a  security  kernel  and  supporting 
software.  Studies  were  done  by  Honeywell  and  MITRE  separately.  At  the  same  time,  MIT 
studied  the  MULTICS  supervisor  tc  see  how  much  of  it  could  be  moved  out  of  Ring  0.  The 
MIT  study  indicated  considerable  reduction  of  Ring  0  code  was  possible  without  complete  re¬ 
structuring  of  the  system  as  a  kernel.  Also,  MIT  identified  potential  performance  problems 
with  kernel.  This  kernel  was  never  built. 

MITRE  Brassboard  Kernel:  This  was  a  prototype  security  kernel  developed  for  a  PDP-11.  Kernel 
operations  were  based  on  the  models  constructed  by  Bell  and  LaPadula.  Performance  was  poor, 
but  good  performance  had  not  been  an  objective  of  the  project.  Both  top-level  and  low-level 
specifications  were  written,  and  extensive  manual  verification  of  the  kernel  operations  and  the 
correspondence  between  specification  levels  was  performed. 

MITRE  Secure  UNIX:  When  MITRE  tried  to  put  a  UNIX  emulator  on  top  of  the  brassboard  kernel, 
they  found  that  the  match  was  so  poor  that  a  new  kernel  was  n^-ded  that  provided  functionality 
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more  suited  to  UNIX.  Formal  specifications  were  written  (referred  to  as  "Parnas" 
specifications),  but  no  verification  was  done. 

UCLA  Data  Secure  UNIX:  This  was  another  prototype  security  kernel  for  a  PDP-11  (parallel  to 
MITRE's),  but  it  was  carried  much  further  than  the  MITRE  implementation  effort.  Its 
architecture  was  based  on  an  implementation  of  "capabilities"  for  the  PDP-11.  A  prototype  was 
developed  and  fitted  with  a  UNIX  user  interface,  but  performance  was  very  slow.  A  separate 
security  model  was  developed  for  this  prototype,  based  on  "data  security";  the  Bell  and  LaPa- 
dula  model  could  be  enforced  by  a  policy  manager  module  running  outside  the  kernel.  A 
strong  effort  to  keep  the  kern'.i  small  resulted  in  a  fair  amount  of  code  outside  the  kernel  that 
did  have  some  security-relevant  functions  (e.g.,  the  policy  manager).  Hence,  comparing  code 
sizes  of  the  UCLA  kernel  and  others  must  be  done  carefully.  Much  effort  was  expended  on 
formal  verification,  in  cooperation  with  ISI  and  the  XIVUS  theorem  prover.  The  effort  seems 
to  have  been  hampered  initially  by  the  lack  of  a  high-level  specification  of  the  system.  This 
lack  seems  to  stem  from  the  philosophy  that  the  only  verification  that  counts  ii  verification  of 
the  lowest  level  assembly  code.  Ultimately,  the  verification  of  about  35  to  40%  of  the  kernel 
code  was  claimed  as  a  feasibility  demonstration  that  the  entire  kernel  could  be  verified,  given 
sufficient  resources. 

Message  Systems  foi  Military  Message  Experiment  (MME):  Three  message  systems  were  developed  in 
competition:  Hermes,  by  BBN;  SIGMA,  by  ISI;  and  MIT-DMS,  by  MIT.  The  ISI  system  won 
the  competition  and  was  used  in  the  MME.  SIGMA  was  designed  as  though  it  were  running  on 
a  security  kernel,  although  the  system  underneath  it  was  not  in  fact  a  kernel-based  system.  A 
"trusted  job"  was  introduced  to  allow  required  operations  that  violated  the  Bell  and  LaPadula 
model  SIGMA  required  users  to  confirm  activity  that  could  cause  insecure  information  flows. 
In  practice,  most  users  confirmed  every  operation  requested  without  understanding  or  thinking 
about  the  implications. 

SHARE-7:  This  Navy  system  developed  at  FCDSSA,  and  implemented  on  the  AN/UYK-7  computer, 
is  in  operational  use  at  several  FCDSSA  installations.  The  system  was  originally  designed  as  a 
virtual  machine  architecture,  to  provide  multiple  AN/UYK-7's  to  users.  More  recently, 
security-kernel  terminology  has  been  used  to  describe  its  security  structure.  It  was  written  in 
CMS-2.  It  is  now  undergoing  security  certification  procedures  for  operation  in  the  controlled 
mode.  (Originally,  certification  for  multilevel  mode  had  been  sought.)  It  is  one  of  the  first 
systems  the  Navy  has  nominated  for  evaluation  by  NSA’s  Computer  Security  Evaluation 
Center. 

DAMOS:  This  is  an  operating  system  developed  by  the  Danish  company  Christian  Rdvsing  (CR)  to 
run  on  its  own  CR80  computer.  The  computer  and  the  operating  system  are  described  as 
capability -based,  and  the  operating  system  includes  implementations  of  a  security  kernel  and 
trusted  processes.  These  concepts  seem  to  have  been  developed  by  CR  independent  of  US 
efforts  in  security  kernels.  DAMOS  is  a  successor  to  an  earlier  system,  AMOS,  and  is  intended 
to  provide  fault  tolerant  operation  in  communication-system  applications.  Systems  in  which 
CR80s  are  or  will  be  used  include  NICS  TARE,  a  NATO  system  for  automating  paper-tape 
relay  operations;  FIKS,  a  Danish  DOD  system  for  message,  packet,  and  circuit  switching;  and 
CAMPS,  a  NATO-SHAPE  message  system  for  communication  centers. 

PROJECTS  UNDER  WAY 

KVM/370:  This  is  an  SDC  project  to  install  a  kernel  underneath  the  IBM  VM/370  operating  system  (a 
virtual  machine-based  system).  Presumably,  the  system  is  near  delivery.  It  has  been  brought 
up  on  IBM  and  Amdahl  hardware.  Performance  is  claimed  o  be  acceptable,  though 
significantly  slower  (approximately  by  half)  than  standard  feVM.  This  seems  to  be  the  only 
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current  project  dealing  with  the  complexities  of  a  large-scale  time-sharing  system  (though  some 
argue  iha>  this  is  really  a  small  system  running  on  large  hardware).  If  successful,  it  will  pri¬ 
marily  provide  multiple  virtual  machines  at  different  security  levels,  with  restricted  communica¬ 
tion  between  machines  handled  via  shared  "minidisks." 

KSQS  (also  known  as  KSOS-II):  This  represents  an  attempt  to  build  a  commercial  prototype  kernel- 
based  system  on  a  POP-1 1/70.  An  emulator  on  top  of  the  kernel  was  to  provide  a  UNIX  inter¬ 
face  to  users.  Full  verification  of  the  security  properties  of  the  kernel  top-level  specification 
(TLS)  (written  in  SPECIAL)  and  demonstration  proofs  of  correspondence  of  code  (written  in 
MODULA)  to  specifications  were  planned.  The  contract  with  FACC  was  terminated  in 
December  1980.  Performance  with  the  UNIX  emulator  and  user  software  layers  was  poor. 
Verification  of  the  kernel  TLS  (using  the  Boyer-Moore  theorem  prover  at  SRI)  seems  to  have 
been  successful.  The  code  proof  demonstrations  were  done  by  hand.  The  kernel  by  itself  may 
prove  useful  as  a  base  for  applications,  but  the  emulator  ended  up  duplicating  kerne!  functions 
and  performed  poorly  in  combination  with  it.  The  Navy  has  funded  Logicon  to  look  into  build¬ 
ing  the  GUARD  application  directly  on  the  kernel. 

SCOMP  (Also  known  as  KSOS-6):  This  project  was  intended  to  parallel  KSOS-ll  but  uses  Honeywell 
Level  6  hardware.  The  U.S.  government  funded  development  of  a  hardware  box  called  the 
Sect  ly  Protection  Module  (SPM)  and  the  kernel  software  specification  and  development.  The 
SPM  monitors  transfers  on  the  bus  without  CPU  interference,  providing  faster  mediation  and 
enhanced  virtual  memory/capability  structure.  The  kernel  and  hardware  are  nearly  complete; 
kernel  performance  on  the  hardware  is  being  tested  now.  Original  plans  called  for  the  develop¬ 
ment  (funded  by  Honeywell)  of  a  UNIX  emulator,  as  in  KSOS-ll;  it  now  appears  that  only  a 
minimal  operating  system  interface,  containing  a  simple  file  system,  will  be  built.  Specification 
of  the  kernel  was  done  in  SPECIAL,  with  verification  using  SRI  tools.  The  verification  was 
substantially  completed,  but  a  few  modules  proved  too  large  to  be  passed  through  the  SRI  tods. 
No  code  proofs  are  planned.  The  kernel  is  coded  in  UCLA  Pascal,  compiled  via  Pascal-to-C 
(UCLA).  The  C-to-Level-6  compiler  was  built  by  DTI.  Trusted  processes  are  to  be  specified  in 
Gypsy,  but  the  current  contract  does  not  cover  verification  of  them. 

GUARD  (ACCAT,  LSI):  ACCAi'  GUARD  (the  original  version  of  GUARD)  provides  a  "trusted" 
path  between  two  database  systems  or  networks  that  operate  at  two  different  security  levels.  It 
supports  operators  who  monitor  requests  made  from  the  low  database  to  the  high  database  and 
sanitize  the  responses  returned.  The  trusted  process  that  performs  downgrading  was  specified  in 
Gypsy  GUARD  was  initially  planned  to  run  on  top  of  the  KSOS  UNIX  emulator,  but  it  is  now 
being  reevaluated  to  see  if  it  can  run  directly  on  the  KSOS  kernel.  A  prototype  version  was 
developed  to  run  on  an  unmodified  UNIX.  LSI  GUARD  is  an  attempt  to  implement  the 
ACCAT  GUARD  functions  directly  on  the  hardware  of  a  DEC  LSI-11  (without  a  kernel)  in 
Euclid.  It  allows  only  a  single  operator,  while  ACCAT  GUARD  can  have  multiple  operators. 

GUARD  (FORSCOM,  RAP,  KAIS):  Each  of  these  GUARDS  is  designed  to  act  as  a  filter  between  a 
terminal  and  a  host  computer  rather  than  as  a  query  monitor  between  two  databases. 
FORSCOM  GUARD  was  built  by  Logicon  based  on  modifications  to  ACCAT  GUARD,  and  it 
is  being  tested  by  the  Army  to  filter  traffic  between  several  WWMCCS  terminals  and  a  single 
WWMCCS  host.  The  system  requires  a  single  human  operator,  who  screens  traffic  for  all  of 
the  terminals.  The  FORSCOM  GUARD  programs  (unlike  those  of  ACCAT  and  LSI  GUARD) 
include  substantial  information  about  the  semantics  of  the  likely  user  activities  on  the 
WWMCCS  host  to  enable  more  accurate  filtering.  FORSCOM  GUARD  was  built  on  top  of 
standard  UNIX  because  KSOS  was  not  available.  Performance  of  the  system  was  adequate  for 
the  Army  to  use  it  in  a  test  mode,  but  it  brought  some  user  complaints. 
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SDC  Communications  Kernel:  This  is  a  project  to  modify  the  UCLA  prototype  PDP-11  kernel  for  use 
in  communications  applications  (packet  switching,  etc.).  The  code  is  written  in  UCLA-Pascal 
and  compiled  using  the  UCLA  Pascal-to-C  translator.  The  kernel  was  heavily  modified  and 
tailored  to  the  application;  no  operating  system  emulator  was  used.  Performance  seems  satis¬ 
factory  at  this  point,  but  some  performance  tests  are  still  pending.  Pascal-to-C  is  not  recom- 
i  ended  for  further  use;  it  takes  about  5  minutes  of  unloaded  PDP-1 1/70  time  to  compile  each 
of  60  submodules,  or  5  hours  for  the  entire  system.  The  requirement  for  verification  of  the 
specification  was  dropped  early  in  the  project;  a  requirement  for  “verifiable"  code  motivated  the 
choice  of  Pascal-to-C,  but  the  only  verification  actually  done  has  been  manual  examination  of 
the  specification  for  information  channels. 

AUTODIN  II:  This  is  a  packet-switched  communication  network  for  military  use,  provided  by  DCA. 
Western  Union  is  the  prime  contractor,  with  Ford  Aerospace  (a  different  group  from  the  KSOS 
group)  and  Computer  Sciences  Corporation  as  software  subcontractors.  The  AUTODIN  II  RFP 
called  for  a  kernel-based  system  for  packet  switching,  but  without  adequately  defining  what  a 
kernel  is  or  what  the  requirements  for  formal  specification  and  verification  were.  There  have 
been  many  problems  in  its  development,  including  a  cfljrt  fight  over  die  definition  of  "formal 
specification."  Eventually,  FACC  wrote  the  code  andSHMaaK  and,tb  some  extent  verified 
(using  Ina  Jo  rnd  ITP),  the  specification  after  the  fact.  The  system  has  apparently  passed  its 
security  and  system  tests,  but  the  date  of  its  availability  to  users  *s  s  ill  uncertain. 

SACDIN:  Originally  named  SATIN  IV,  this  was  to  be  a  packet  switching  net  for  SAC,  but  the  Air 
Force  was  directed  to  use  AUTODIN  II  for  the  network  backbone.  The  SATIN  IV  RFP  was 
thought  to  be  better  (with  respect  to  security)  than  AUTODIN  II;  the  SACDIN  development 
is  somewhat  less  rmbitious  than  the  original  plan.  IBM  is  working  as  a  subcontractor  to  ITT, 
building  a  kernelized  system.  A  top-level  specification  was  written  and  verified,  but  the  imple¬ 
mentation  is  in  assembly  language  (for  IBM  Series  i  computers)  and  no  code  proofs  are 
planned.  No  mapping  between  the  sp<  cification  and  the  code  has  been  constructed. 

COS/NFE:  This  DCA  project  with  DTI  is  an  effort  to  build  a  secure  network  front  end  for  WWMCCS 
using  the  DTI-proprietary  HUB  architecture  (HUB  a  trademark  of  DTI).  SDC  is  a  subcontrac¬ 
tor  to  DTI  for  specification  and  verification,  using  Ina  Jo  and  ITP.  According  to  DTI,  the  HUB 
executive  is  a  security  kernel.  Top-level  and  second-level  specifications  for  the  HUB  have  been 
written,  and  security  criteria  for  it  have  been  developed  and  proven  to  hold  for  the 
specifications  (bo  '  levels).  The  security  criteria  are  based  on  maintaining  a  strict  separation  of 
"security  level  seis."  The  HUB  structure  includes  many  modules  that  will  process  data  at 
several  securitj  levels;  these  are  termed  "trusted"  modules.  Whether  formal  low-level 
specifica'i  Jos  Aill  be  written  and  verified  against  the  code  is  still  an  open  question.  The  whole 
system  is  intended  to  be  small,  fast,  and  application-driven.  It  is  being  written  in  Pascal  for 
POP  1 1  architecture.  An  early  s, reification  was  written  in  Euclid. 

GNOSIS:  This  is  a  new  operating  system  built  by  Tymshare.  claimed  to  be  based  on  an  implementation 
of  capabilities  for  IBM  370  architecture.  No  formal  specification  or  verification  was  done,  but 
an  important  motive  in  developing  the  system  was  to  be  able  to  protect  timesharing  customers’ 
data  from  theft,  so  muc*'  attention  was  paid  to  protection  (though  not  to  military  security). 
The  system  is  in  operational  use  by  its  developers,  but  is  not  commercially  available  as  yet. 

PSOS:  An  initial  specification  for  a  "Provably  Secure  Operating  System"  (PSOS)  was  written  by  SRI  in 
the  mid  to  late  1970s.  This  document  was  used  as  part  of  a  product  description  for  a  two-phase 
contract  finally  awarded  in  early  1980  to  Ford  Aerospace  as  prime  contractor  for  the  sjftware, 
with  Honeywell  as  a  subcontractor,  primarily  to  provide  software,  but  also  to  provide  some  help 
with  verification.  The  goal  is  a  moderate-  to  large-scale,  general  purpose,  verified  (or 
verifiable)  computer  system,  not  kerneiized.  The  first  phase  is  for  a  design  only;  the  second 
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phase,  if  awarded,  will  be  Tor  development.  The  plan  is  to  build  a  capability-based  system,  with 
proofs  of  the  entire  OS  specification.  It  is  unclear  whether  code  proofs  will  be  done. 
Honeywell  bid  32-bit  minicomputer  hardware  that  looks  like  a  next-generation  Level  6,  with 
SPM  (see  SCOMP).  Unsuccessful  bidders  were  Burroughs  (software  and  hardware)  and 
SDC/Univac.  The  phase-one  contract  was  terminated  in  May,  1981;  the  fate  of  the  second 
phase  (for  construction)  is  unknown. 

Message  Flow  Modulator  A  iiow  modulator  is  a  system  that  receives  messages  from  a  source,  filters 
out  certain  messages,  transforms  messages  that  pass  the  filter,  and  transmits  the  resulting 
messages  to  a  sink.  A  flow  modv'Uor  with  a  null  transform  is  like  a  GUARD,  and  a  Row 
modulator  with  a  nu-1  filter  and  an  encrypti*  algorithm  for  a  transform  is  like  a  standard 
encryption  device.  Don  Good's  group  at  the  University  of  Texas  has  developed  a  simple  flow 
modulator  using  Gypsy  and  the  Gypsy  tools,  and  has  proven  some  properties  about  the  system. 
Present  work  on  the  system  is  aimed  at  applying  it  to  a  Navy  system. 

Secure  Archival  Storage  System:  The  goal  of  this  project  is  to  apply  security  kernel  technology  to  a  net¬ 
work  of  microprocessors  that  store  multilevel  files.  Ultimately,  SASS  would  provide  a  shared, 
secure  archival  storage  for  a  variety  of  host  computers.  The  initial  implementation  is  on  a  sin¬ 
gle  Z8000  processor  and  is  being  carried  out  by  Roger  Schell,  Lyle  Cox,  and  a  number  of  grad¬ 
uate  students  at  the  Naval  Postgraduate  School.  Although  there  are  no  plans  to  verify  the 
design  or  the  implementation,  and  the  design  seems  not  to  have  been  specified  formally,  the 
authors  consider  the  security  kernel  to  be  "verifiable." 

PROJECTS  PLANNED 

GUARD  (RAP,  KAIS):  RAP  GUARD  is  to  be  used  by  NASA  in  a  shuttle  planning  systeni  between 
the  terminals  and  other  network  components.  MITRE  is  working  or*  the  design  of  this  system 
and  a  similar  one  for  the  Korean  Air  Intelligence  System  <KAlo).  In  each  of  these  three  sys¬ 
tems,  the  GUARD  component  includes  some  knosuge  about  the  activities  the  user  (at  the 
terminal)  is  performing  on  the  host,  as  in  FOitSCOM  GUARD,  (e.g.:  Was  the  last  command 
an  editing  command  that  has  a  stereotyped  response  or  a  database  query  that  could  provide 
significant  information  to  (he  user?)  They  are  intended  to  operate  between  a  single  terminal 
and  a  single  host,  and  are  not  intended  to  require  an  operator.  They  are  intended  to  filter  out 
classified  material  of  inappropriate  levels  without  human  intervention. 

WWMCCS  Local  Network:  The  evolutionary  path  of  WWMCCS  and  WIN  is  intended  to  lead  to  a  set 
of  local  networks,  interconnected  by  packet  switching  (AUTODIN  II)  trunks.  (All  of  this  is 
called  the  WWMCCS  Information  System  {WIS]  architecture.)  SDC  presented  three  scenarios 
for  a  trusted/multilevel  secure  local  network  to  a  committee  convened  by  DCA  in  February 
1981.  The  goal  was  to  identify  which  scenario  would  be  realistic  to  specify  in  an  RFP  to  appear 
in  FY82/83.  The  most  conservative  scenario  presented,  which  involved  separate  local  networks 
at  different  security  levels,  connected  by  a  GUARD-like  security  filter  box,  was  recommended. 
Additional  studies  of  the  architects e  are  to  be  conducted. 

MITRE  MLS  Terminal:  This  project  is  investigating  the  practicality  of  dealing  with  multilevel  objects 
by  assigning  a  separate  microprocessor  to  handle  each  security  level,  with  a  "trusted  feedback 
monitor"  to  coordinate  their  activities.  A  design  has  been  produced  based  on  a  word-processing 
application,  and  there  are  plans  to  implement  it. 

MMS/TDMS:  This  is  an  NRL  project  (funded  by  NAVELEX)  to  design  a  prototype  Military  Message 
System  viewed  as  a  Trusted  Data  Base  Management  System.  A  contract  was  let  to  SDC  to 
develop  design  specifications  and  to  work  on  the  proposed  MMS  security  model.  BBN  has  also 
participated. 
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MITRE  DBMS  Kernel:  This  is  a  MITRE  project  to  specify  and  implement  a  kernel  designed  specifically 
to  support  a  database.  The  SCOMP  (Honeywell  Level  6  with  Security  Protection  Module 
fSPMl)  is  to  be  the  hardware  base,  and  the  MRS  database  management  system  is  the  most 
likely  to  be  used. 

NON-U. S.  WORK 

Germany:  EIFEL  is  a  German  air  traffic  control  network  (perhaps  also  command  and  control)  that  is 
due  for  a  new  generation  of  hardware  and  software  (TIFEL  2).  The  German  equivalent  of 
MITRE  was  (in  1980)  trying  to  write  a  specification  for  the  system  that  included  multilevel 
secure  operation.  Siemens,  Telefunken,  and  others  were  also  investigating  the  problem  as  pros¬ 
pective  bidders. 

Canada:  The  Canadian  Maritime  Command  is  appaiently  attempting  to  procure  a  system  that  may  have 
a  multilevel  security  requirement. 

England:  There  is  some  interest  in  the  security  problem  at  the  Royal  Signals  and  Radar  Establishment 
(RSRE),  Malvern.  At  last  report  their  central  interest  was  control  flow  analysis  of  programs 
and  low-level  cod'*  ,,  ..nation. 
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Fourth  Seminar  on  the  DOD  Computer  Security  Initiative  Program ,  held  at  the  National  Bureau  of  Stan¬ 
dards  in  August  1981.  Some  of  the  'papers"  in  these  proceedings,  however,  are  only  copies  of  the 
viewgraphs  used  in  oral  presentations.  These  proceedings  should  be  available  from  the  Office  of  the 
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